The refresh button's title and red-when-stale logic was designed for
the polling era and is misleading under SSE: lastCheckedTime only ticks
on real history changes (so the "Last refreshed Xs ago" text describes
nothing actionable), the 2-minute idle cutoff goes red even when SSE
is healthy, and the click handler called the idempotent
startWatchingHistory which short-circuits once initialized — clicking
did nothing.

In SSE mode the button now shows "Refresh history" with a normal link
variant, and only turns red ("Live updates disconnected. Click to
refresh.") when the SSE socket actually drops after a previous
successful open (gated on the new sseEverConnected latch in
useNotificationSSE so the brief initial-connect window isn't flagged
as an outage). Clicking now forces a real refresh via
refreshHistoryFromPush in both modes. Polling-mode title/variant is
unchanged.

Adds a HistoryCounter Vitest covering the SSE healthy / initial /
lost transitions plus the polling-mode legacy behavior.

Owner dispatch only delivers history_update events to the user who owns
the changed history. Watching a shared or pinned non-owned history
(e.g. via the multi-history view) silently received nothing under SSE
because the dispatch path keys on history ownership and there was no
way for a viewer to opt in.

Add an additive viewer-subscription channel: the client POSTs the
history ids it wants pushes for to /api/events/history-subscriptions,
the dispatcher fans the record out to every webapp worker over Kombu,
and history_update fanout pushes to subscribed viewers in addition to
the owner. Subscriptions are refcounted on the client and replayed on
every EventSource onopen so reconnects don't drop them. Per-worker
subscription state is purged when a user's last connection on that
worker closes; the client's onopen replay re-asserts the desired set.

No authorization check on the dispatch path: SSE events only carry
history ids, the client follows up with a normal access-controlled
REST fetch, and leaking "history changed at T" pings is acceptable.

MultipleViewItem now subscribes whenever it renders a history the
current user does not own and SSE is enabled; owned histories continue
through owner dispatch with zero subscribe round-trip.

Tests: integration test exercising subscribe -> mutate -> receive ->
unsubscribe -> stop receiving end-to-end, plus vitest for the client
refcount and replay logic.